1. Field of the Invention
The present invention relates generally to a system and method for limiting access to sub-programs in a software system.
2. Background Information
With reference to FIG. 1, there is illustrated a logical diagram of a typical software system 10 formed of a number of software programs 11-1 to 11-5 and attendant sub-programs 13-6 to 13-8. Each of exemplary user interface program 11-2, security operation program 11-4, funds operations program 11-5, and hardware control program 11-3 is capable of being executed at the request of the operating system program 11-1. Likewise, the exemplary sub-programs 13-6 to 13-8 are capable of being executed by their corresponding programs 11-4, 11-5, 11-3 respectively. For example, security operations program 11-4 is capable of issuing a call to invoke one or more functions embodied in security management sub-program 13-6. Similarly, funds operations program 11-5 is capable of issuing a call to invoke one or more functions embodied in funds management sub-program 13-7. Likewise, hardware control program 11-3 is capable of issuing a call to invoke one or more functions embodied in hardware access sub-program 13-8.
As used herein, “program” refers to machine readable code stored on an electronic medium that is capable of being invoked via the execution of a command contained within operating system program 11-1. Furthermore, as used herein, “sub-program” refers to a function, or collection of functions (also sub-programs), that may be invoked via a call from a program or other sub-program. As such, for example, security management sub-program 13-6 is either one sub-program, or a collection of more than one sub-programs related by a common functionality (in this case, security management).
Typically, sub-programs 13-6 to 13-8 perform sensitive tasks, such as those related to security, hardware access, or funds management. Such sub-programs 13-6 to 13-8 are therefore enabled to access and alter sensitive data. It is therefore important to prevent nefarious access to the invocation of the sub-programs 13-6 to 13-8. To maintain secure access to the sub-programs 13-6 to 13-8, the sub-programs 13-6 to 13-8 are typically stored in memory internal to the microprocessor that is to execute the sub-programs 13-6 to 13-8. Examples of such internal memories include flash memory and RAM.
However, sequestering the sub-programs 13-6 to 13-8 in internal memory is not always sufficient to guarantee that undesirable and potentially nefarious access to the operations of the sub-programs is prevented. Often times, the software forming the programs 11 and sub-programs 13 are authored by more than one individual or company. The programs 11 and sub-programs 13 are subsequently integrated to form a single executable image. Under normal operating conditions, there are no restrictions placed on the entities which can invoke sub-programs. As a result, for example, systems that utilize security and funds management can be compromised by software utilizing security and funds management sub-programs 13-6, 13-7 in a manner outside the designed parameters of the system.
As illustrated, execution of the operating system program 11-1 results in the coordination of the execution of programs 11-2 to 11-5. Such coordination is typically performed through the use of an Operating System's intertask messages. As noted above, sub-programs 13-6, 13-7, and 13-8 are accessed by their corresponding programs 11-4, 11-5, 11-8, respectively.
However, because traditional implementations do not restrict calls from one sub-program to another sub-program, an opportunity for unauthorized or unwanted access to the sub-programs exists. With reference to FIG. 2, there is illustrated the exemplary typical software system 10 of FIG. 1 wherein there is indicated communication between sub-programs. Specifically, hardware access sub-program 13-8 is illustrated as making direct calls to security management sub-program 13-6 and funds management sub-program 13-7. As a result, malicious code operating in the hardware access sub-program 13-8 can make direct calls to both security management sub-programs 13-6 and funds management sub-programs 13-7. Such malicious code may operate to misallocate funds or circumvent security procedures.
There is therefore needed a method by which malicious code forming a sub-program can be prevented from accessing the operation of other sub-programs.